Timeline is uncertain for release of normative version of FHIR
Variances in dates reflect desire to offer realistic expectations, says Chuck Jaffe, MD.
As the healthcare industry eagerly awaits a normative version of Health Level Seven International’s Fast Healthcare Interoperability Resources data exchange standard, the timeline for realizing a stable version remains murky, with HL7 executives offering different opinions.
Work is continuing to advance FHIR, and it's being used by some large vendors in an increasing number of situations. But many vendors are waiting for HL7 to get farther along in its standard-setting process before investing in the development needed to incorporate FHIR into their products. A significant milestone for any standard is when it reaches a normative version--that is, a mature standard that works in most cases and most industry participants accept as essential to use.
FHIR continues to mature as an open standard for exchanging healthcare data between information systems. According to FHIR Product Director Graham Grieve, STU3 Standard for Trial Use, release 3 (STU3)—the third major milestone for the initiative—is expected to be published in late March.
“Once STU3 is published, we will start working on release 4,” wrote Grieve in a product roadmap posted online last month. He noted that release 4 (R4) is expected to be the first normative version of FHIR, “where the standard becomes stable, and breaking changes are no longer considered.”
Under the planned timeline, the first draft of R4 will be published for comment in December 2017; the first R4-based connectathon will take place in January 2018; an R4 ballot is slated for April 2018; ballot reconciliation would be set for May to September 2018; and final publication of FHIR R4 would occur in October 2018.
However, this schedule stands in contrast to the timeline outlined by HL7 CEO Chuck Jaffe, MD, who said last month that the normative version of FHIR is slated for release sometime in 2017.
Also See: 2017 emerges as pivotal year for FHIR interoperability standard
“Release 4 should be introduced in the fall of this year, although I don’t think anyone on the FHIR development team wants to be held to a specific date,” comments Jaffe, who says that he and Grieve have discussed the schedule at length.
Grieve was not immediately available for comment.
Asked why Grieve’s timeline differs significantly from his own, Jaffe suggests that perhaps the FHIR product director is offering a more conservative timeframe “because he doesn’t want to disappoint people” and “if he says something that delights people because it’s six months earlier (than he proposed), well that’s great and nobody will complain—but, if he proposes a date and can’t meet it, then there will be all sorts of disappointment.”
Jaffe goes on to say, “I can’t tell you with any real honesty that I know that by the end of calendar 2017 we’ll be balloting a stable version of (FHIR) release 4…It’s safe to say that we’re encouraged that we’ll be on that timeline, but no one wants to commit to a date with which we’ll promise to ballot release 4.”
David McCallie, MD, Cerner’s senior vice president of medical informatics, agrees with Jaffe that “we’ll probably see a normative ballot in 2017.” At the same time, McCallie contends that “the fact that it’s a normative ballot is less important than the maturity level of a particular FHIR resource.”
He emphasizes that, “within FHIR itself, there is a wide range of what they call maturity index, so you may have a normative ballot that includes some very immature specifications—and, that’s different from the way HL7 did it in the past.” As a result, according to McCallie, electronic health record vendors such as Cerner will “pay attention to that maturity level in their decisions as to whether to implement it or not, rather than to the fact that it’s the normative ballot.”
At the same time, just because the normative version of FHIR is not yet finalized and published does not mean that providers and vendors are waiting for release 4.
“People aren’t waiting for the normative version to implement,” says Stan Huff, MD, chief medical informatics officer at Intermountain Healthcare. “We have some not only FHIR but also SMART on FHIR based applications that are in production use.”
Cerner is also committed to implementing FHIR, which is already a part of its product offering, with the emerging standard serving as the basis for the company’s open application programming interface (API), according to McCallie.
“We’re quite excited about FHIR and are actively supporting it both through collaborative work like the Argonaut Project as well as allowing developers to use FHIR to access data in the Cerner EHR,” says McCallie. “We will continue that and support expansion of the APIs that we can offer using FHIR as the standard.”
Micky Tripathi, president and CEO of the Massachusetts eHealth Collaborative and manager of the Argonaut Project, an industry-wide effort to accelerate the development and adoption of FHIR, says this kind of vendor-specific decision is common regarding when the emerging standard is mature and stable enough for their production purposes.
Vendors, particularly smaller companies, might “skip” STU3 and wait for release 4, Tripathi believes. “Some of them may decide to hold off, particularly if release 4 is really just around the corner,” he says. “However, the Cerners, Epics and athenahealths of the world are not sitting around waiting for the normative version of FHIR before they implement. Epic and Cerner already have FHIR implementations out there, and they’re continuing to build on those.”
Nonetheless, Cerner’s McCallie adds “that doesn’t mean we’ll implement all of FHIR.” He sees the emerging standard as a “giant moving target—you can’t sort of say the whole thing is ready, although there may be parts of it that are quite stable and mature.” When it comes the normative version of FHIR (release 4), McCallie believes different parts of it will be more ready for implementation than other parts, even once it goes through a normative ballot.
“There are parts of FHIR, even though they may become normative sometime later this year, we might not put them into the EHR for years,” says McCallie. “In fact, there are parts of FHIR that will never get implemented by any EHR vendor. It’s not all equally relevant to us.”
While Huff is “very positive” about FHIR, he observes that “even when FHIR is a normative standard, it will not be truly interoperable,” adding a “note of caution—there’s still a lot of work to do.”
Huff, who is co-chair of HL7’s Clinical Information Modeling Initiative (CIMI) aimed at improving the interoperability of healthcare systems through shared implementable clinical information models, warns that what’s needed is the “standard use of terminology and codes” to ensure that these systems are “truly semantically interoperable.”
Also See: Emerging FHIR standard just the start of interoperability efforts
“I don’t want anything that I’m saying to be taken as disparaging or understood as me saying we shouldn’t do FHIR—we should do FHIR,” concludes Huff. “I’m saying we need to get it to the level of true semantic interoperability.”
Work is continuing to advance FHIR, and it's being used by some large vendors in an increasing number of situations. But many vendors are waiting for HL7 to get farther along in its standard-setting process before investing in the development needed to incorporate FHIR into their products. A significant milestone for any standard is when it reaches a normative version--that is, a mature standard that works in most cases and most industry participants accept as essential to use.
FHIR continues to mature as an open standard for exchanging healthcare data between information systems. According to FHIR Product Director Graham Grieve, STU3 Standard for Trial Use, release 3 (STU3)—the third major milestone for the initiative—is expected to be published in late March.
“Once STU3 is published, we will start working on release 4,” wrote Grieve in a product roadmap posted online last month. He noted that release 4 (R4) is expected to be the first normative version of FHIR, “where the standard becomes stable, and breaking changes are no longer considered.”
Under the planned timeline, the first draft of R4 will be published for comment in December 2017; the first R4-based connectathon will take place in January 2018; an R4 ballot is slated for April 2018; ballot reconciliation would be set for May to September 2018; and final publication of FHIR R4 would occur in October 2018.
However, this schedule stands in contrast to the timeline outlined by HL7 CEO Chuck Jaffe, MD, who said last month that the normative version of FHIR is slated for release sometime in 2017.
Also See: 2017 emerges as pivotal year for FHIR interoperability standard
“Release 4 should be introduced in the fall of this year, although I don’t think anyone on the FHIR development team wants to be held to a specific date,” comments Jaffe, who says that he and Grieve have discussed the schedule at length.
Grieve was not immediately available for comment.
Asked why Grieve’s timeline differs significantly from his own, Jaffe suggests that perhaps the FHIR product director is offering a more conservative timeframe “because he doesn’t want to disappoint people” and “if he says something that delights people because it’s six months earlier (than he proposed), well that’s great and nobody will complain—but, if he proposes a date and can’t meet it, then there will be all sorts of disappointment.”Jaffe goes on to say, “I can’t tell you with any real honesty that I know that by the end of calendar 2017 we’ll be balloting a stable version of (FHIR) release 4…It’s safe to say that we’re encouraged that we’ll be on that timeline, but no one wants to commit to a date with which we’ll promise to ballot release 4.”
David McCallie, MD, Cerner’s senior vice president of medical informatics, agrees with Jaffe that “we’ll probably see a normative ballot in 2017.” At the same time, McCallie contends that “the fact that it’s a normative ballot is less important than the maturity level of a particular FHIR resource.”
He emphasizes that, “within FHIR itself, there is a wide range of what they call maturity index, so you may have a normative ballot that includes some very immature specifications—and, that’s different from the way HL7 did it in the past.” As a result, according to McCallie, electronic health record vendors such as Cerner will “pay attention to that maturity level in their decisions as to whether to implement it or not, rather than to the fact that it’s the normative ballot.”
At the same time, just because the normative version of FHIR is not yet finalized and published does not mean that providers and vendors are waiting for release 4.
“People aren’t waiting for the normative version to implement,” says Stan Huff, MD, chief medical informatics officer at Intermountain Healthcare. “We have some not only FHIR but also SMART on FHIR based applications that are in production use.”
Cerner is also committed to implementing FHIR, which is already a part of its product offering, with the emerging standard serving as the basis for the company’s open application programming interface (API), according to McCallie.
“We’re quite excited about FHIR and are actively supporting it both through collaborative work like the Argonaut Project as well as allowing developers to use FHIR to access data in the Cerner EHR,” says McCallie. “We will continue that and support expansion of the APIs that we can offer using FHIR as the standard.”
Micky Tripathi, president and CEO of the Massachusetts eHealth Collaborative and manager of the Argonaut Project, an industry-wide effort to accelerate the development and adoption of FHIR, says this kind of vendor-specific decision is common regarding when the emerging standard is mature and stable enough for their production purposes.
Vendors, particularly smaller companies, might “skip” STU3 and wait for release 4, Tripathi believes. “Some of them may decide to hold off, particularly if release 4 is really just around the corner,” he says. “However, the Cerners, Epics and athenahealths of the world are not sitting around waiting for the normative version of FHIR before they implement. Epic and Cerner already have FHIR implementations out there, and they’re continuing to build on those.”
Nonetheless, Cerner’s McCallie adds “that doesn’t mean we’ll implement all of FHIR.” He sees the emerging standard as a “giant moving target—you can’t sort of say the whole thing is ready, although there may be parts of it that are quite stable and mature.” When it comes the normative version of FHIR (release 4), McCallie believes different parts of it will be more ready for implementation than other parts, even once it goes through a normative ballot.
“There are parts of FHIR, even though they may become normative sometime later this year, we might not put them into the EHR for years,” says McCallie. “In fact, there are parts of FHIR that will never get implemented by any EHR vendor. It’s not all equally relevant to us.”
While Huff is “very positive” about FHIR, he observes that “even when FHIR is a normative standard, it will not be truly interoperable,” adding a “note of caution—there’s still a lot of work to do.”
Huff, who is co-chair of HL7’s Clinical Information Modeling Initiative (CIMI) aimed at improving the interoperability of healthcare systems through shared implementable clinical information models, warns that what’s needed is the “standard use of terminology and codes” to ensure that these systems are “truly semantically interoperable.”
Also See: Emerging FHIR standard just the start of interoperability efforts
“I don’t want anything that I’m saying to be taken as disparaging or understood as me saying we shouldn’t do FHIR—we should do FHIR,” concludes Huff. “I’m saying we need to get it to the level of true semantic interoperability.”
More for you
Loading data for hdm_tax_topic #better-outcomes...